m: I believe this might be better suited to live in DECISIONS.md

I agree, once a decision is made - would it be better to open this for discussion as an issue and close this out?

I think we can keep this doc open and collapse it into a decision at the end.

My main concern with this approach is that we have to add KSCrash to the dependencies in Package.swift, and every user needs to check it out, even if they do not use it. There is no conditional compilation flag for Package.swift

Yup, that is the main downside (one I will note in the doc as well). In testing it's a ~3.3MB checkout with SPM which seemed negligible - if you know of a better way to integrate this (until the cut over) I'm happy to not add it as a direct dependency.

If we accept the downside of having KSCrash as a dependency even if we don't use it yet (gated by feature flag), I would also go with this option so we can do releases with partial functionality (if applicable) and have a full V10 testing setup on main rather than very late with a massive PR to review

I would say "no merge cliff" or "'flip the switch' change" are only true if the KSCrash-related CI is fully integrated on main and blocks PRs, if something broke. Otherwise, this still relieves us from continuous sync efforts, but we defer the pain.

That is true however, v10 code is already expected to be buildable by the CI and would block PRs merging. The testing side currently isn't integrated, but by the time the work is set to be delivered this should be integrated and blocking. Do you mean something else I've not considered?

v10 code is already expected to be buildable by the CI

Sure, buildable is great, but far from "no merge cliff". For "no merge cliff", I would expect not only builds but all tests to run for v10 and block PRs.

I think this is not a "con" in its own right. That is just a fact of this option. However, regarding "merge cliff" etc., an essential con is that if this should really be integrated early and provide feedback, PRs for v9 might be blocked by tests that cover a rather global invariant for v10.

We could express this as a separate option "C" or an option to the option, but the crux with option B is: do we want to integrate early so we have "no merge cliff" and "no conflict mess", or are we happy with solely "no conflict mess". The former means PR blocking CI for V10, the latter means V10 being colocated on the same branch.

Understood - I'll schedule some time this week to think about this aspect. Maybe it would be acceptable to the team to skip SentryCrash tests in v10 mode. Otherwise I'll incorporate this feedback into the document - thanks!

Just to be clear: this doesn't have to be a biggie or even an up-front decision; it should just calibrate expectations, and our written assumptions should reflect that.

If we are interested in flipping the switch, then the test battery must run continuously. Even if v9 PRs aren't outright blocked, there should be something obviously red enough for us to act on (that is what I meant yesterday in our sync).

If we only colocate and build together to primarily reduce the churn from continuously syncing two branches, then we should be aware that we do not have feedback on whether main v9 and v10 drift on global invariants (some of which are not expressible via interfaces or types in general). And that means we must allocate some time after flipping the switch.

After a chat with the team, we decided to use another build flag for just KSCrash so they're colocated but will have different CI runs and test for now.